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Resume : Dans un monde exigeant le meilleur retour sur performances possible d'un investisse- 
ment financier, les applications distribuees occupent la premiere place parmi les solutions proposees. 
Cela s'explique notamment par les performances potentielles qu'elles offrent de par leur architecture. 
Actuellement, de nombreux travaux de recherche visent a concevoir des outils pour faciliter la mise en 
oeuvre de ces applications distribuees. Le besoin urgent de telles applications dans tous les domaines 
pousse les chercheurs a accelerer cette procedure. Cependant, le manque de standardisation se traduit 
par r absence de prises de decisions strategiques par la communaute informatique. Dans cet article, 
nous argumentons que la technologic Java represente le compromis recherche et preside ainsi la liste 
des solutions disponibles actuellement. En favorisant I'independance du materiel et du logiciel, la 
technologic Java permet, en effet, de surmonter les ecueils inherents a la creation des applications 
distribuees. 

Mots-cles : Java, Middleware, RMI, Applications distribuees. Modes de communications 
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Java Technology : a Strategic Solution for Interactive Distributed 

Applications 



Abstract: In a world demanding the best performance from financial investments, distributed ap- 
plications occupy the first place among the proposed solutions. This particularity is due to their dis- 
tributed architecture which is able to acheives high performance. Currently, many research works aim 
to develop tools that facilitate the implementation of such applications. The urgent need for such appli- 
cations in all areas pushes researchers to accelerate this process. However, the lack of standardization 
results in the absence of strategic decisions taken by computer science community. In this article, we 
argue that Java technology represents an elegant compromise ahead of the list of the currently avail- 
able solutions. In fact, by promoting the independence of hardware and software, Java technology 
makes it possible to overcome pitfalls that are inherent to the creation of distributed applications. 

Key- words: Java, Middleware, RMI, Distributed applications. Communication Modes 
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1 Introduction 

Aujourd'hui, de nombreuses organisations (entreprises, administrations, 
etc.) ont besoin d'applications a grande echelle pour supporter leurs activites 
complexes. A travers ces applications, les utilisateurs cooperent a la reali- 
sation des differentes activites de leur organisation. Ces activites evoluant 
fortement avec le temps, toute application distribuee, et par voie de conse- 
quence sa conception, se doit de repondre rapidement a ces changements. La 
misc cn ocuvrc distribuee dcs applications s'avere fort utile dans ce cadre car 
elle bcncficic de revolution dcs interconnexions reseaux reliant des ressources 
virtuellement illimitees. En effet, cela permet d'elargir le champ d'utilisation 
des applications distribuees, permettant de toucher toutes sortes d'activites. 

L'cmploi d'applications distribuees repose sur la mise en place d'un grand 
nombrc dc machines interconnectces par des reseaux gcncraux. Ces appli- 
cations peuvent etre classifiees selon I'infrastructure materielle utilisee en 
deux categories : les systemes bases sur des grappes de machines (egalement 
appelees clusters), ou les machines sont intcrconnectees via un reseau local 
caractcrisc par une faiblc latcnce et une bandc passantc clcvcc ; ct les sys- 
temes bases sur les grilles oii les machines (et / ou des grappes) , souvent tres 
heterogenes, sont fortement reparties geographiquement en etant intercon- 
nectees par dcs reseaux longue distance (de type Internet). 

Le dcveloppement intense d'applications, dans un contexte distribue, 
reste encore delicat de par la pauvrete des modeles dc programmation pour 
les systemes distribues et suite au lourd heritage des applications develop- 
pees dans un contexte centralise. Ceci amplifie le besoin d'une solution pra- 
tique pour la mise en ccuvre dc ces applications. Les processus d'une appli- 
cation distribuee ne sont pas necessairement identiques, mais ils cooperent 
pour atteindre les buts de I'application. Cette collaboration se realise suivant 
plusieurs modeles de repartition. 

En raison de I'heterogeneite des environnements distribues, deux proble- 
matiques majeures sont rencontrees lors du developpement d'applications 
distribuees : I'integration et I'interoperabilite de celles-ci. Le langage Java 
et son environnement d'execution JVM {Java Virtual Machine) s'imposent 
dans ce cadre comme une voie determinante dans le deploiement d'applica- 
tions distribuees, en particulier sur I'lnternet. 

Sans perte de generalite, les applications peuvent etre classees en trois 
categories : 

1. Utilisation intensive du processeur (CPU-intensive) 

Ces programmes demandent beaucoup de cycles CPU pour accomplir 
leurs taches. lis effectuent des calculs mathcmatiques ou symboliques 
(manipulation de chaines ou d'images, par excmple) demandant beau- 
coup de temps. Ces programmes ont besoin de peu (ou pas de tout) 
d'entrees de la part de I'utilisateur ou de sources externes. 
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2. Utilisation intensive des entrees/sorties (I/O-intensive) 

Ces applications passent la majorite de leur temps en attente de la fin 
d'operations d'entrees/sorties : lecture ou ecriture sur disque, ou sur 
un socket reseau, communication avec une autre application. 

3. Interactivite avec I'utilisateur 

Ces programmes interagissent avec les entrees utilisateur. Le deroule- 
ment d'une application interactive donnee pent comporter difFerentes 
phases. En reponse a une action particuliere de I'utilisateur, I'applica- 
tion entre dans une phase « CPU-intensive » ou bien « I/O-intensive », 
puis se remet en attente d'une autre commande. Dans cet article, nous 
sommes plutot interesse par les applications de cette categorie. 

La suite de Particle s'organise de la maniere suivante. Tout d'abord, 
nous survolons les caracteristiques des applications distribuees. Dans un se- 
cond temps, nous presentons une taxonomie des modeles de communication 
utilises pour developper des applications distribuees. Finalement, nous es- 
sayons de demontrer que la technologie Java constitue une voie strategique 
pour remedier a la fois aux problematiques des applications distribuees et a 
I'exigence des developpeurs en termes de simplicite et d'interoperabilite. 

2 Caracteristiques des applications distribuees 

Aujourd'hui, un des defis les plus importants de I'informatique est de 
maitriser la conception, la realisation et le deploiemenlj^des applications dis- 
tribuees, afin d'offrir un large eventail de services evolutifs accessibles, aussi 
bien par le grand public que par des utilisateurs «experts». Pour ce faire, 
de nombreuses caracteristiques orthogonales doivent etre prise en compte : 
la communication entre les applications, I'heterogeneite de celles-ci, I'inte- 
gration de I'existant et I'interoperabilite. Ces caracteristiques doivent etre 
traitees de front par les concepteurs d'applications distribuees. 

• Communication 

Un service distribue est compose de differents elements logiciels et 
materiels mis en oeuvre dans sa realisation : des interfaces d'inter- 
actions pour les utilisateurs, des logiciels de service (ou serveurs), des 
machines, des espaces de stockage, des reseaux, des protocoles de com- 
munication/dialogue entre les machines mais aussi entre les logiciels. 
Tons les logiciels dialoguent selon un protocole client/serveur : les 
clients sont les applications destinees a I'utilisateur final, les serveurs 
sont les applications gerant les informations et les ressources partagees 
au sein des organisations. Comme ces applications sont distribuees sur 

^Le deploiement d'une application distribuee consiste en la diffusion de programmes 
executables, leur installation et leur configuration sur les sites de leur future exploitation. 
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differents sites, il est necessaire de les faire communiquer afin qu'elles 

cooperent pour realiscr un travail commun. 

La communication s'effectue par I'intermediaire d'une infrastructure 
entre machines distribuees, en I'occurrence le reseau. Cette infrastruc- 
ture doit permettre I'interconnexion des machines a travers differents 
types de reseaux physiques et offrir des mecanismes de communication 
entre les appHcations distribuees. 

• Heterogeneite 

L'heterogeneite logicielle des environnements est due a la grande di- 
versite des technologies proposees par I'industrie de I'informatique. A 
tous les nivcaux d'un systeme informatiquc, dc nombrcuscs solutions 
techno logiques peuvent etre envisagccs. Les rcscaux Internet ct Intra- 
net sont des exemples concrets de tels systemes heterogenes (divers 
types d'ordinateurs, fonctionnant sous differents systemes d'exploita- 
tions ; varictc des protocolcs assocics au reseaux). 
Heterogeneite des cquipcmcnts. Les cquipements utilises par les appli- 
cations reparties, qu'ils soient des terminaux d'acces aux applications 
ou des infrastructures de communication utilisees par ces terminaux, 
se sont diversifies, traduisant clairement une heterogeneite materielle. 
Les terminaux pcuvcnt ctrc aussi bicn des stations dc travail que des 
ordinateurs portables, ou encore des PDA. De meme, les reseaux utili- 
ses peuvent etre des reseaux sans fil de proximite (du type technologic 
Bluetooth, par exemple), des reseaux telephoniques sans fil (UMTS) 
ou des reseaux filaires locaux ou a grande echelle. 

• Integration 

L'heterogeneite permet done d'utiliser la meilleure combinaison de 
technologies (materielles et logicielles) pour chaque composant de I'in- 
frastructure informatiquc d'une organisation. Cependant, il faut apla- 
nir les differences issues de l'heterogeneite et done integrer ces diffe- 
rentes technologies afin d'offrir un systeme coherent et operationnel. 
Parallelement a I'integration de nouvelles technologies, les entreprises 
ont aussi besoin de preserver leurs applications « patrimoines » (ou 
legacy applications). Ces applications sont souvent indispensables au 
fonctionnement de ces entreprises et il serait tres couteux, voire inutile, 
de les remplacer. 

L'integration de I'existant avec les nouvelles technologies doit alors 
preserver les investissements passes et offrir de nouveaux services aux 
entreprises. Cependant, I'integration de technologies heterogenes s'avere 
generalcmcnt complexe et necessite des plates-formes d'execution re- 
parties et souples. 
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• Interoperabilite 

Lorsqu'une organisation developpe ses propres applications en interne, 
elle pent toujours trouver des solutions proprietaires pour resoudre les 
trois points cvoques precedemment. Neanmoins, la mise en oeuvre de 
solutions proprietaires differentes au sein d'organisations est un frein a 
leur cooperation. Ainsi, la seule maniere d'atteindre I'interoperabilite 
entre les systemes informatiques est de definir des normes acceptees 
et suivies par tons les actcurs impliques dans la cooperation. Afin 
d'etre universellement acceptees, ces normes doivent etre definies au 
sein d'organismes de standardisation ou de consortiums internationaux 
rcgroupant Ic maximum d'actcurs (des industries, des administrations, 
des organismes public de recherche, etc.). 

Les contraintes evoquees precedemment rendent complcxc Ic dcveloppe- 
ment d'applications distribuees. D'autre part, les applications distribuees 
necessitent souvent la mise en oeuvre de mecanismes generaux permettant 
de trouver sur le reseau des rcssourccs partagces, d'assurer la securite des 
communications, de realiser des traitcments transactionnels et de fournir la 
persistance des informations partagees. II est alors evident que nous ne pou- 
vons pas implanter ces mecanismes lors du developpement de chaque nou- 
velle application. II est done necessaire de factoriser les parties communes 
a toutes les applications et de ne developper que les parties nouvelles de 
celles-ci. Pour atteindre cette factorisation et masquer les quatre contraintes 
precedentes, comme nous allons le voir, plusieurs modeles de repartition des 
logiciels ont ete developpes avec le temps. Ces modeles peuvent repondre 
« plus ou moins » aux besoins des applications distribuees. 

3 Modeles de repartition des applications distri- 
buees 

D'un point de vue operatoire, une application distribuee pent se definir 
comme un ensemble de processus s'executant sur differents sites communi- 
quant entre eux par envois de messages. Pour faciliter la programmation 
de telles applications, et notamment la mise en oeuvre des communications 
entre processus, differents modeles de programmation ont ete developpes. 
Naturellcmcnt, ces modeles doivent prendre en compte I'hcterogeneite, I'in- 
tegration et I'interoperabilite des applications distribuees. On pent classer 
ces modeles en quatre categories suivant le paradigme de communication 
utilise par les processus. Nous allons maintenant presenter ces quatre para- 
digmes. 
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3.1 Communication par messages 

Les processus communiquent par echange explicite de messages a travers 
le reseau de communication. La synchronisation est egalement realisee par 
des primitives d'envois de messages. Selon la forme des messages echanges, 
on distingue trois types de communication dans ce modele de repartition : 

1. Communication orientee paquet 

Ce type de communication permet d'echanger des messages entre des 
machines distantes a travers un reseau via, par exemple, le protocole 
IP. Ce niveau de communication est necessaire mais il est difficile a 
utiliser pour construire des applications distribuees, car le program- 
meur doit gerer trop de problemes (duplication, perte, retransmission 
et non ordonnancement des paquets). 

2. Communication orientee flux 

Elle offre une communication point a point entre des processus, ceux-ci 
se transmettant des flux de donnees en utilisant des canaux de commu- 
nications (des sockets TCP/IP, par exemple). Les processus dialoguent 
grace a des primitives de lecture {read) et ecriture {write). Les develop- 
peurs peuvent ainsi batir plus facilement des applications distribuees, 
mais ils doivent encore se preoccuper du format des donnees echangees, 
de r ordonnancement et de la structuration du dialogue (envoi, attente 
et reception de donnees), ainsi que de la designation des ressources. 
La communication orientee flux forme un mecanisme de communica- 
tion permettant uniquement de transmettre des paquets en octets non 
structures d'un executable vers un autre, sans gerer les differences de 
formats de donnees des deux processus executant ces programmes. 

3. Communication par envois de messages structures 

Ce dernier type de communication fournit cette structuration des don- 
nees en message et defini des modes de dialogue : synchrone ou asyn- 
chrone, bloquant ou non, avec ou sans tampon. Dans ce contexte, les 
processus dialoguent grace a des primitives d'envoi {send) et de recep- 
tion {receive). Ainsi, I'envoi bloquant signifie que le processus emet- 
teur restera bloque tant que les donnees a envoyer ne seront pas toutes 
emises. De meme, dans le cas de la reception bloquante, le processus 
recepteur sera fige aussi longtemps que toutes le donnees ne seront 
pas regues. Le mode bloquant est utilise lors d'une communication 
peu liable, ou bien lorsqu'il est important d'envoyer/recevoir les mes- 
sages dans un ordre specifique. Pour ce qui est des communications 
non-bloquantes, celles-ci permettent le recouvrement des communica- 
tions par le calcul, puiqu'il n'y a plus d'attente au moment de I'envoi 
ou de la reception des messages. 

Ce type de couche de communication est souvent bati au dessus d'une 
couche orientee flux. La norme MPI [Ij est les bibliotheques PVM [2] 
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ou PM2 [3], en sont des exemples significatifs, qui sont d'ailleurs tres 
utilises pour implementer des d'applications distribuees. II est a noter 
que PVM, tout comme la majorite des implementations de MPI n'ont 
pas de mecanisme de tolerance aux pannes. MPICH-V |4j est I'une des 
implementations tolerantes aux pannes, elle est basee sur MPICH [5]. 
Enfin, il faut remarquer que ces environnements ne fournissent pas de 
fonctionnalites telles que I'equilibrage de charge ou la migration de 
t aches. 

Le modele de repartition fonde sur la communication par messages a 
souvent constitue une reponse efficace aux problemes de performances des 
applications de calcul scientifique. II est accessible a travers des bibliotheques 
de programmation qui sont difficiles a mettre en oeuvre. Aussi, dans de pe- 
tites applications il n'est pas difficile de mettre en place un ensemble de mes- 
sages a echanger entre les processus de 1' application. En revanche, dans de 
grandes applications cet ensemble devient complique et difficile a maintenir. 
De plus, etendre cet ensemble afin d'y integrer de nouvelles fonctionnalites 
est une tache encore plus fastidieuse. 

D'autre part, n'etant pas directement integre dans les langages de pro- 
grammation, ce modele n'est pas naturel pour la plupart des developpeurs. 
Par exemple, une decomposition explicite des donnees est necessaire pour 
les distribuer. Cela a abouti au developpement d'un modele de repartition 
different, plus simple et plus robuste notamment pour les applications re- 
parties a grande echelle. Suivant ce modele, les processus d'une application 
distribuee partagent les « objets » plutot que de les echanger. 

3.2 Objets partages 

Par objets partages, nous entendons des donnees localisees dans une me- 
moire partagee distribuee, notee DSM |6] (pour Distributed Shared Memory). 
Ainsi, les processus « partagent » virtuellement de la memoire, meme s'ils 
s'executent sur des machines qui ne la partagent pas physiquement. Grace 
a ce mecanisme les processus peuvent acceder de maniere uniforme a n'im- 
porte quel objet partage, que celui-ci soit local ou non. Autrement dit, avec 
une DSM, une meme operation pent induire des acces a distance ou non. 
De plus, I'acces se fait de maniere transparente pour le programmeur (il n'a, 
par exemple, pas besoin de savoir oii sont reellement stockees les donnees). 
A I'inverse, dans un modele de communication par passage de messages, 
I'acces aux donnees non locales est explicite. Cela signifie que dans ce cas le 
programmeur doit decider quand un processus doit communiquer, avec qui 
et quelles donnees seront envoyees. La difficulte du controle assure par le 
programmeur augmente avec le degre de complexite de la structuration des 
donnees et des strategies de parallelisation. On constate done qu'avec une 
DSM, le programmeur pent se concentrer pleinement sur le developpement 
algorithmique, plutot que sur la gestion des objets partages. 
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Les DSM peuvent etre difFerenciees suivant trois criteres : 

1. L'implementation 

Une memoire partagee distribuee peut etre implementee soit au ni- 
veau du systeme d'exploitation, soit a travers une bibliotheque de- 
diee. Lorsque la DSM est mise en oeuvre par une modification du sys- 
teme d'exploitation, elle peut etre vue comme une extension de la 
memoire virtuelle. L'avantage etant que cela rend la DSM complete- 
ment transparente au developpeur. On peut citer Kerrighed [7, comme 
un exemple d'un tel systeme. L'implementation par une bibliotheque 
dediee ne permet pas d'atteindre le meme degre de transparence, par 
contre cette approche est plus portable. 

2. Le fait qu'elles soient structurees ou non 

Dans le cas d'une DSM non structuree, celle-ci apparait comme un 
tableau lineaire d'octets. En revanche, I'utilisation d'une DSM struc- 
turee permet aux processus d'acceder la memoire au niveau objets (au 
sens programmation orientee objets) ou des tuples (composes de suites 
d'au moins un element type), comme Linda |8] par exemple. Ce sont les 
langages de programmation utilises qui structurent ou non une DSM. 
En pratique, une DSM est generalement organisee en memoire sous 
forme de pages. Cela engendre le probleme du faux partage, probleme 
qui peut etre utilise en utilisant des protocoles a ecriture multiple. 

3. Les protocoles de coherence 

Un objet partage consiste en une succession de version^ traduisant 
revolution de ses valeurs associees durant I'execution de I'application 
distribuee. 

Afin d'assurer une vision coherente des successions de versions des 
objets partages aux differents processus, le systeme DSM utilise des 
protocoles de coherence {consistency protocol) . Ces protocoles assurent 
la coherence des objets partages en adoptant une strategie de mise a 
jour des objets incoherents ou d'invalidation. Une strategie basee sur 
I'invalidation donne generalement de meilleures performances, car une 
strategie de mise a jour souffre plus des effets de faux partage [S]. 
La coherence des objets partages signifie que lors d'une lecture de 
la valeur d'un objet, c'est la derniere valeur ecrite qui doit etre lue. 
Malheureusement, la notion de derniere valeur ecrite n'est pas toujours 
bien definie. C'est pourquoi, la valeur lue d'un objet n'est pas toujours 
la derniere valeur ecrite. 

Les DSM different suivant le modele de coherence implemente dans 
les protocoles. On distingue plusieurs modeles, selon la precision de 

■^Une version est dite en attente si une tache peut encore ecrire cette version ; prete si 
aucune tache ne peut plus ecrire cette version ; terminee si aucune tache ne pourra jamais 
plus ni la lire, ni 1' ecrire. 
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la notion de derniere valeur ecrite (chacun de ces modeles pent etre 
plus ou moins bien adapte a une application donnee). II est note que 
comme le coiit de I'envoi de messages est relativement eleve, moins le 
modele de coherence est strict plus la performance est amelioree. Les 
difFerents modeles peuvent etre regroupes en deux categories selon le 
mode d'acces aux objets partages. En efFet, un objet partage pent etre 
accede avec un acces synchronise ou non. Les outils de synchronisa- 
tion classiques sont : verrous, barrieres et semaphores. Lors d'un acces 
synchronise, I'objet est acquis par un processus, empechant tout autre 
processus d'y acceder jusqu'au relachement de I'objet. 

• Coherence sans synchronisation 

- Coherence sequentielle {sequential consistency) 

Ce modele de coherence est sans doute le plus fort. En effet, il 
garantit que la derniere valeur ecrite sera propagee vers tous les 
processus des que possible, suivant un ordre sequentiel particu- 
lier |10j . Ce modele reduit la performance globale du systeme, car 
des messages sont envoyes, approximativement, pour chaque assi- 
gnation a un objet partage pour lequel il y a des copies valables 
en suspens. Ivy [11] et Mirage [12] ont adoptes ce modele. 

- Coherence causale {causal consistency) 

Par rapport au modele precedent, il s'agit un modele alterna- 
tif [13^ . II garantit la coherence sequentielle des objets en relation 
causale, i.e. que le fait d'acceder a un objet pent avoir des conse- 
quences sur I'acces a un autre. Remarquons que les objets qui 
ne sont pas en relation causale peuvent etre vus dans des ordres 
differents dans les divers processus. 

- Coherence de processeur {processeur consistency ou PRAM consis- 
tency) 

II s'agit d'un modele moins fort. La sequence des operations d'ecri- 
ture effectuees par un processus est vue par chaque processus dans 
I'ordre oii ces operations ont ete effectuees. Cependant I'ensemble 
des operations d'ecriture effectuees par les differents processus 
pent etre vu par chaque processus dans des ordres differents [Hj. 

• Coherence avec synchronisation 

- Coherence faible {weak consistency) 

Ce modele induit une coherence sequentielle lors d'un acces syn- 
chronise aux objets partages [15] . II garantit egalement la propaga- 
tion des modifications effectuees par un processus lorsque celui-ci 
accede des objets partages en mode synchronise. Le processus est 
lui aussi informe des modifications intervenues auparavant dans 
les autres processus. 

- Coherence a la sortie {release consistency) 
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Ce modele est encore moins fort, puisqu'il assure seulement que 
la memoire est mise a jour au niveau de points de synchronisation 
bien precis. Suivant la position des points de synchronisation, on 
pent identifier deux modeles de coherence a la sortie : 
o mise a jour precoce {eager release consistency) 

Assure la coherence d'un objet partage lorsqu'il est libere, cela 
pour tons les processus. Le systeme multiprocesseur DASH |T6] 
est une implementation typique de ce modele. 
o mise a jour paresseuse {lazy release consistency) 

Garantit egalement la coherence d'un objet partage lors de 
sa liberation, mais uniquement pour le processus cherchant a 
r« acquerir » [T7]. Ce modele est plus performant que le mo- 
dele precedent, car il requiert moins de communications entre 
processus. TreadMarks [18] adopte, par exemple, ce modele. 

- Coherence a I'entree {entry consistency) 

A I'instar de la coherence a la sortie, ce modele assure que la 
memoire est mise a jour lors de I'acces a I'objet [TH] . Ainsi, dans 
ce cas un objet devient coherent pour un processus seulement 
lorsqu'il acquiert cet objet. De plus, les seuls objets pour lesquels 
on a une garantie sont ceux acquis par le processus. Ce modele 
de coherence est plus faible que les autres, mais permet d'obtenir 
une meilleure performance. 

- Coherence de portee {scope consistency) 

Modele representant un compromis entre une coherence a I'entree 
et une coherence a la sortie « paresseuse ». Plus precisemment, il 
est similaire a la lazy release consistency, mais avec les avantages 
de la coherence a I'entree. Cela se fait grace a la notion de portee 
coherente [20^ consistant en un regroupement des objets acquis 
par un nceud. Ce modele est adopte dans JIAJIA [211 . 

II existe egalement des systemes qui supportent plusieurs modeles de 
coherence simultanement. Par exemple, Midway [22] permet d'activer 
plusieurs modeles dans une meme application : coherence de proces- 
seur, a la sortie, a I'entree. Munim [23], lui egalement, utilise plusieurs 
modeles de coherence selon les differents types des objets partages 
{write once, write many, result, migratory, producer /consumer, gene- 
ral read/write and synchronization). Les systemes recents gerant une 
DSM, comme Millipede [21], integrent I'usage des environnements mul- 
tithreades. 

On constate done que I'utilisation d'une DSM est plutot souhaitable du 
point de vue programmation, puisqu'elle rend transparente la gestion 
des objets partages. Cependant, cette approche est moins performante 
(elle est egalement moins populaire). En effet, I'implementation de la 
DSM repose sur un mecanisme « convertissant » la memoire partagee 
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en echanges de messages, aboutissant a des communications supple- 
mentaires par rapport au modele precedent. 

De fait, bien que dans le modele de communication par passage de 
messages le programmeur soit en charge de la gestion de toutes les 
communications (plus de travail), cela presente deux avantages. D'une 
part d'avoir une gestion plus efficace des communications, d'autre part 
une vue complete de I'organisation des donnees de I'application (ce qui 
n'est pas le cas d'un systeme gerant une DSM). Notons qu'en pratique 
le surcout en communications induit par I'utilisation d'une DSM est 
limite pour des configurations mettant en jeu peu de noeuds, ainsi 
que pour certains algorithmes. A titre d'exemple, TreadMarks permet 
d'atteindre de 76% a 99% des performances obtenues avec PVM dans 
certaines applications, notamment dans le domaine du calcul scienti- 
fique [25] . Le point essentiel d'un systeme utilisant une DSM est de 
veiller a ce que les communications implicites des donnees evitent les 
problemes de coherence des objets partages. 

3.3 Appel de procedure a distance 

L'appel de procedure a distance ou Remote Procedure Call (RPC) 
est un mode de communication de haut niveau, utilise notamment sur In- 
ternet. II offre une solution plus transparente et plus structurante du point 
de vue genie logiciel, permettant d'appeler des fonctions situees sur une ma- 
chine distante, tout en s'efforgant de maintenir le plus possible la semantique 
habituelle des appels. Le resultat est double : une integration plus naturelle 
dans les langages de programmation proceduraux; un paradigme facile et 
bien connu des programmeurs pour implementer des applications distribuees 
de type client /serve ur. Ce mode de communication permet de concevoir une 
application comme un ensemble de procedures distribuees dans les divers 
processus serveurs. 

L'objectif du mecanisme RPC est de masquer au processus client la 
couche de communication et la localisation distante de la procedure appelee. 
Ainsi, comme le montre la figure [T] l'appel de procedure a distance est 
identique a un appel local pour le processus client. La transparence de cette 
approche est facilitee par les procedures stubs ou souches qui sont generees 
automatiquement par un pre-compilateur a partir d'une description de la 
signature des procedures. Les problemes lies a I'heterogeneite des machines 
sont pris en charge dans les souches par une conversion des donnees vers un 
format unique, tel que XDR {eXternal Data Representation). 

Bien que 1' implementation des RPC soit aisee, ce mode de communi- 
cation n'est pas tres usite dans le domaine du calcul scientifique distribue. 
La principale raison vient de la nature bloquante des appels. En effet, lors- 
qu'un processus client RPC appelle une methode distante, il reste bloque 
(attente active) en attendant la reponse du processus serveur. Neanmoins, 
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Fig. 1 - Les difFerentes etapes d'un appel de procedure distante. 

ce modele est parfaitement adapte aux applications dont I'architecture est 
de type client / serveur. Les plates-formes les plus frequemment utilisees sont 
DCE [27] [Distributed Computing Environment!) de V Open Software Fonda- 
tion et les RFC de Sun |28j . 

L'approche RFC introduit une methode de gestion des formats de don- 
nees heterogenes, neanmoins cette methode a une granularite trop impor- 
tante pour faire communiquer des objets distants. De fait, elle permet d'in- 
voquer une procedure d'un processus plutot qu'une methode d'un objet d'un 
processus. Dans le contexte oriente objets, ce probleme est resolus par une 
extension de RFC, a savoir I'invocation d'objets distants. Ce mecanisme 
d'appel de methode a distance (voir la figure [2| a ete introduit dans une 
version distribuee du langage SmallTalk (distributed SmallTalk) et dans le 
langage Modula-3 sous le nom de Network objects). Ces environnements ge- 
nerent automatiquement les souches de communication a partir de I'interface 
des objets. 

Le principal defaut de cette approche est sa limitation a certains langages 
de programmation. Cette specificite s'oppose aux besoins d'interoperabilite, 
de reutilisation de composants issus de langages differents et d'integration 
d'applications patrimoines. Le protocole SOAF [29] {Simple Object Access 
Protocol), bati sur XML, semble un bon remede a ce probleme d'interope- 
rabilite. 
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Fig. 2 - Invocation d'une methode distante. 



3.4 Logiciels mediateurs (ou middlewares) 

Les differents mecanismes decrits jusqu'a present sont sou vent soit de 
trop bas niveau, soit trop specialise pour construire des applications distri- 
buees fortement heterogenes. Ainsi, ils resolvent uniquement les problemes 
de communication et d'heterogeneite, laissant les developpeurs faire face 
aux besoins d'integration et d'interoperabilite des applications. Problemes 
qui peuvent etre resolus par 1' utilisation de logiciels mediateurs, egalement 
appeles middlewares ou intergiciels ISDJ . 

Les logiciels mediateurs se situent au-dessous de I'applicatif, au-dessus 
du systeme d'exploitation, entre deux logiciels ayant besoin de communiquer 
entre eux (ce point est illustre par la figure [s]) . lis offrent des services evolues 
et directement integrables dans les applications, avec les avantages suivants : 

• Independance entre applications et systeme d'exploitation 

Chaque systeme d'exploitation offre des interfaces de programmation 
specifiques pour controler les couches de communication reseau et les 
peripheriques materiels. Un logiciel mediateur fournit aux applications 
des interfaces standardisees, masquant les specificites de chaque sys- 
teme. 

• Portabilite des applications 

Les interfaces standardisees permettent de concevoir des applications 
portables et independantes des environnements d'execution. Les sources 
des applications peuvent alors etre recompilees sur differents environ- 
nements sans la moindre modification. 

• Services partages 

Les applications distribuees requierent des fonctionnalites systemes 
telles que la communication, la securites, les transactions, la localisa- 
tion, la designation, I'administration, etc. Les intergiciels fournissent 
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Fig. 3 - Mise en oeuvre d'un logiciel mediateur. 



ces fonctionnalites sous la forme de services partages sur I'ensemble 
des sites. 

Les logiciels mediateurs proposent des interfaces objets specifiees dans 
un langage independant des differ entes implementations de ces interfaces. 
II existe de nombreux logiciels mediateurs. Ainsi, ODBC {Open DataBase 
Connectivity) definit une API permettant a des applications clientes de com- 
muniquer avec des bases de donnees, ceci par I'intermediaire du langage SQL. 
La norme CORBA [31] ( Common Oriented Request Broker Architecture) ou 
1' architecture EAI {Enterprise Application Integration) sont des intergiciels 
qui s'inscrivent dans la famille des logiciels mediateurs orientes objets. Une 
autre famille est celle regroupant les middlewares orientes messages (MOM 
- Messages Oriented Middlewares) [32] tels que WebSphere MQ d'IBM ou 
MSMQ {Microsoft Message Queuing). 

Les intergiciels se doivent d'etre de facto standardises, afin d'etre por- 
table et de garantir I'interoperabilite. A I'heure actuelle, I'interoperabilite 
offerte n'est pas complete, I'interoperabilite entre logiciels mediateurs n'est 
en particulier pas assuree alors que des passerelles entre middlewares peuvent 
s'averer necessaires. En effet, I'heterogeneite ne concerne pas uniquement les 
architectures materielles et les langages de programmation, mais egalement 
les logiciels mediateurs. Cette problematique, a laquelle repond le concept 
de M2M {Middleware to Middleware [33]), emerge du fait de I'utilisation de 
composants pre-existants. CORBA doit, par exemple, pouvoir interoperer 
avec WebSphere MQ. 
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4 Une nouvelle couche de logiciels ? 

La definition d'un nouveau modele de repartition pent consister a spe- 
cialiser un modele existant. C'est par exemple le cas de Dream [33], qui 
est un modele hybride communication par messages-objets partages. Autre 
exemple, Minimum CORBA qui specialise CORBA pour les systemes em- 
barques. A I'inverse, le modele de repartition d'Ada 95 regroupe dans une 
meme annexe, dediee aux systemes distribues (DSA), les objets partages, 
I'appel de procedure a distance, les logiciels mediateurs, fonctionnalites sou- 
vent mise en oeuvre dans des plates-formes distinctes. 

Toutefois, I'emergence, I'extension ou la specialisation des modeles de 
repartition est rendu difficile par la contradiction entre les objectifs de I'in- 
teroperabilite et la nouvelle forme d'heterogeneite engendree par la multipli- 
cite des modeles. Assurer I'interoperabilite entre les modeles de repartition 
devient alors un nouvel enjeu technologique. L'interoperabilite pent etre 
abordee de maniere statique par I'elaboration d'un schema de traduction 
d'une entite d'un modele de repartition en une entite d'un autre modele. 
Cependant, cette correspondance s'avere souvent delicate et les solutions se 
limitent a deux modeles sans permettre de passage a I'echelle. Par exemple, 
CIAO [35^ fournit des passerelles statiques de DSA vers CORBA. 

Une approche consiste a ameliorer les logiciels mediateurs de maniere a ce 
qu'ils soient configurables, permettant d'ajouter ou de retirer, statiquement 
ou dynamiquement, des mecanismes au modele de repartition initial. Dans 
ce contexte, la configurabilite autorise I'utilisateur a choisir les composants 
a mettre en oeuvre, comme dans TAO [36] qui constitue une plate- forme 
configurable pionniere, ou encore GLADE [3T, la premiere implementation 
de DSA se caracterisant par une forte configurabilite. Neanmoins, les logi- 
ciels mediateurs classiques n'offrent souvent qu'une configurabilite statique, 
limitee a certains composants, n'autorisant pas en general la selection d'un 
comportement particulier pour un composant. De plus, passer d'une configu- 
ration a une autre requiert generalement une refonte de la conception d'une 
partie de son application. Obtenir une meilleure flexibilite passe done par la 
definition d'une architecture dont les composants faiblement couples soient 
reconfigurables independamment. 

Aussi, une approche plus generique consiste a etendre le concept de confi- 
gurabilite par la production d'un logiciel mediateur generique ou personna- 
lisable en fonction d'un modele de repartition. Ainsi, une instanciation pour 
un modele de repartition donne constitue une personnalite de I'intergiciel 
mediateur generique. Certains composants de 1' architecture generique sont 
reutilises, d'autres surcharges en fonction du modele de repartition. C'est le 
cas de Quarter Ware [38] qui s'illustre par une conception s'appuyant sur des 
gabarits de conception, ou encore de Jonathan [39] qui adopte une approche 
originale fondee sur les liaisons inspirees par le modele ODP ( Open Distribu- 
ted Processing). Toutefois, I'architecture des logiciels mediateurs generiques 
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et les elements qui les composent reste mal etablis, donnant encore lieu a de 
nombreux travaux de recherche. 

Une solution plus globale, unifiant les concepts d'interoperabilite, de 
configurabilite et de genericite, est la definition d'un logiciel mediateur schi- 
zophrene. Dans ce cadre, la schizophrenie caracterise la capacite d'un in- 
tergiciel a disposer, simultanement, de plusieurs personnalites afin de les 
faire interagir efficacement (cf. figure [4]). Cela se traduit par I'aptitude de 
produire des passerelles dynamiques entre logiciels mediateurs. Un logiciel 
mediateur schizophrene permet de partager le code entre difFerents logiciels 
mediateurs sous forme d'une couche neutre du point de vue personnalite. 
Cette couche neutre propose d'une part des services qui sont independants 
de tout modele de repartition et une, d'autre part une representation com- 
mune des donnees. EUe se caracterise egalement par des composants qui 
contribuent a la factorisation du code entre personnalites, masquant done 
I'incompatibilite entre personnalites. 
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Fig. 4 - Mise en oeuvre d'un logiciel mediateur schizophrene. 

D'autres solutions que la proposition de logiciels mediateurs schizophrenes 
etant envisageables, il n'est irrealiste de voir apparaitre un nouvelle couche 
de logiciels. Le tout est de savoir si la proposition de solutions induisant 
de nouvelles formes d'heterogeneite et les problemes de leurs integration et 
interoperabilite sous-jacents s'averera encore pertinent dans le futur. 

Une couche supplementaire unique : une machine virtuelle 

L'interoperabilite entre modeles de repartition represente une proble- 
matique pour laquelle les solutions presentees precedemment ne sont guere 
satisfaisantes. D'un autre cote, le developpement d'applications distribuees 
reste un besoin incontournable. Aussi, pour satisfaire ce besoin, et en at- 
tendant la standardisation des couches logicielles ou I'adoption de nouvelles 
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solutions, pourquoi ne pas profiter de technologies disponibles et satisfai- 
sant les contraintes posees par les applications distribuees? Autrement dit, 
utilise! une seule couche permettant de masquer au niveau applicatif les spe- 
cificites de I'ordinateur, et plus precisement son architecture ou son systeme 
d 'exploitation. Cette couche d'abstraction permet ainsi d'executer I'applica- 
tion sans aucune modification, quelles que soient les caracteristiques de la 
plate-forme sous-jacente. Elle est plus communement appelee une machine 
virtuelle applicative ou plus simplement machine virtuelle. 

Une machine virtuelle est un programme qui imite les operations d'un 
ordinateur, executant un langage assembleur virtuel qui lui est propre (le 
hyte code) associe a un processeur generique tout aussi virtuel. C'cst done 
un ordinateur abstrait qui comme une vraie machine possede un ensemble 
d'instructions, manipule des regions memoire differentes, offrant I'abstrac- 
tion d'un environnement homogene. Le resultat est une transparence de 
rhctcrogcncitc des plates-formes pour les developpeurs. De fait, toutes les 
implementations d'une machine virtuelle donnee out un comportement ex- 
terne identique grace aux specifications qui decrivent son architecture interne 
abstraite. 

Pour executer une application sur une machine virtuelle donnee, I'ap- 
plication (developpee sur une plate-forme quelconque) doit etre compilee 
dans un format intermediaire, independant de toute plate-forme d'execution. 
Comme note plus haut, ce format est appelc hyte code. Le resultat est qu'au 
lieu de compiler I'application dans un code natif pour chaque plate-forme 
(toute modification ulterieure de I'application necessitera une recompilation 
pour chaque plate-forme) , elle est compilee une fois dans un byte code pour 
une machine virtuelle donnee. Cela confere done la caracteristique de porta- 
bilite a I'application, puisque celle-ci pent fonctionner sur toute plate-forme 
supportant cette machine virtuelle. De plus, il est d'une part plus aise de 
faire evoluer une application compilee dans un byte code, et d'autre part sa 
mise en place est plus rapide. 

Le byte code n'est pas directement executable tel quel par le processeur 
reel d'un ordinateur. A chaque lancement d'une application il est interprete 
au fur et a mesure par la machine virtuelle et traduit en code natif pour 
la plate-forme. Malheureusement, cette interpretation a la volee affaiblit les 
performances de I'application cxccutcc. Toutcfois, bicn que moindrc, les per- 
formances obtenues en interpretant du byte code sont en general meilleures 
comparees a celles resultant d'un langages interprete tel que Perl, Python, 
PHP ou bien encore Tel. 

Afin de minimiscr le ralentissement induit par interpretation du byte 
code par les machines virtuelles, plusieurs solutions out ete proposees. Un 
compilateur JIT {Just In Time), par exemple, interprete le byte code en 
code natif avant execution, place les resultats dans un cache, les utilisant 
au cas par cas suivant les besoins. Ceci permet, dans bien des situations, a 
I'application de n'avoir des performances que legerement inferieures a celles 
des codes natifs (compile pour un seul type de plate-forme). Les compi- 
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lateurs JIT sont presque toujours plus rapide qu'un interpreteur, les plus 
recents sont meme capables d 'identifier le code qui est frequemment exe- 
cute et d'optimiser exclusivement la vitesse de celui-ci. Les ameliorations 
constantes permettront sans doute d'obtenir a terme des performances si- 
milaires a celles des compilateurs « classiques ». 

La machine virtuelle Java 

L'utilisation de machines virtuelles remonte a I'epoque des P-machines 
(ou pseudo-code machine) dans les annees soixante-dix. Elles executaient du 
P-code (une sorte de byte-code), le resultat de la compilation des premiers 
compilateurs Pascal. D'autres exemples de machines virtuelles sont la ma- 
chine virtuelle Parrot pour le langage Perl et celles du langage Smalltalk 
(Smalltalk-80, Digitalk, etc.). A I'heure actuelle, la machine virtuelle la plus 
connue et la plus usite est sans aucun doute la machine virtuelle Java, ou 



La machine virtuelle Java s'est imposee grace a sa large diffusion. En ef- 
fet, elle a ete adaptee a toute sorte de materiels, allant des superordinateurs 
a des systemes de navigation pour voiture ou des bornes de paiement dans 
les parkings, en passant par les ordinateurs et telephones portables. Cette 
multiplicite de plates-formes fait que la JVM est consideree comme la refe- 
rence pour les applications distribuees, en particulier pour les applications 
sur Internet. 

La JVM presente plusieurs caracteristiques qui sont tres interessantes : 
• Ramasse-miettes automatique 

Ce service facilite le travail du programmeur en le dechargeant de la 
gestion de la memoire. Toutefois, c'est d'une part moins rapide qu'une 
gestion manuelle, d'autre part le programme est plus gourmand en 
memoire et plus lent au demarrage (dans le cas d'applications impor- 



• Securite 

Comme la JVM a ete congue initialement pour executer le byte code 
de programmes transmis via le reseau Internet (Applet), elle comporte 
des mecanismes de securite. Le premier est la verification, si besoin, 
du byte code avec un algorithme d'authenfication a cle publique avant 
interpretation. Ceci permet de bloquer I'acces au disque local ou au 
reseau sans autorisation, garantit la validite du byte code et assure 
que ce dernier ne viole pas les restrictions de securite de la JVM. En 
second lieu, la machine virtuelle Java rend impossible certains types 
d'attaque, comme la surcharge de la pile d'execution, I'endommage- 
ment de la memoire exterieure a son propre espace de traitement, la 
lecture ou I'ecriture de fichiers sans permission. Enfin, la JVM controle 

^EUe a ete creee par Sun Microsystems en 1995, resultat du projet « Green ». D'autres 
implementations de la JVM existent, comme la JVM d'IBM ou JRockit de BEA Systems. 
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egalement I'execution de I'application en temps reel a I'aide de la no- 
tion de classe signee numcriquement. Ainsi, il est possible de savoir 
qui est I'auteur d'une classe donnee et ainsi de determiner I'ampleur 
des privileges accordes a cette classe en fonction de la confiance envers 
son auteur. 

• Monitoring 

Par ailleurs, les serveurs d'applications peuvent utiliser les capacites 
de surveillance de la machine virtuelle Java pour accomplir diverses 
t aches : 

- repartition automatique de la charge ; 

- regroupement des connexions aux bases de donnees ; 

- synchronisation d'objcts ; 

- arret et redemarrage des mecanismes de securite ; 

- etc. 

Les programmeurs ont interet a utiliser ces fonctionnalites sophisti- 
quees, plutot que de les developper. Ainsi, ils peuvent se concentrer 
sur la logique de traitement de son application. 

• Interpreteurs JIT 

Toutes les JVM disponibles pour les differentes plates-formes, a I'ex- 
ception de celles du type telephone portable, fournissent des interpre- 
teurs JIT, permettant d'obtenir de bonnes performances. Ccs bonnes 
performances s'expliquent en partie par le fait que le resultat de la 
translation de byte code en code natif est memorise a Tissue du pre- 
mier appel lors d'une execution. En outre, a partir de la version 1.5 
Sun a integre la technologic HotSpot (un compilateur JIT) dans ses 
JVM. Cette version optimisee de la JVM existe dans une version ser- 
veur et une version pour les clients, la version serveur est en particulier 
interessante dans le contexte des servlets. La machine virtuelle « HotS- 
pot » ameliore encore les performances en cffectuant plusieurs taches 
supplement aires, telles que la decouverte des goulets d'etranglement 
ou la recompilation en code natif des parties de code frequemment 
utilisees. 

• Compilateurs pour de nombreux langages 

A la base, le byte code est Ic resultat de la compilation d'applications 
ecrites en Java. Or, attire par le principe de « write once, run eve- 
rywhere » (ecrit une fois et execute partout) et afin de tirer parti des 
caracteristiques avantageuses de la JVM, des compilateurs produisant 
du byte code ont etc proposes pour d'autres langages. On pent citer 
SmalltalkJVM et Talks2 pour Smalltalk, AppletMagic et GNAT pour 
Ada 95, PERCobol pour Cobol, NetProlog pour Prolog, bien en- 
tendu, le langage Java rcste le langage preponderant, du fait de ses 
caracteristiques (presentees plus loin. La possibilite de produire du 
byte code a partir de differents langages constitue une solution prag- 
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matique pour profiter des capacites specifiques de chaque langage tout 
en conservant une interoperabilite maximale. II est ainsi possible d'in- 
tegrer aisement le travail de plusieurs programmeurs maitrisant des 
langages differents, minimisant de fait le temps de developpement de 
I'application. 

II faut noter que les machines virtuelles, en particulier les JVM, souffrent 
d'une reputation de lenteur : les applications gourmandes en puissance de 
calcul sont incontestablement plus lente que leurs equivalents C ou C++, y 
compris en utilisant un interpreteur JIT. Naturellement, dans le cas d'appli- 
cations recourant intensement a des entrees-sorties ou inter actives, limitees 
par la bande passante, ce probleme est mineur. Aussi, dans ce cadre les 
avantages de Java, comme sa nature mi-compile/mi-interprete, le charge- 
ment dynamique des classes, le ramasse-miettes, etc., prennent le dessus. 
Enfin, la reputation de lenteur conferee a Java date de ses origines, I'amelio- 
ration constante des machines virtuelles permet a I'heure actuelle d'obtenir 
des performances tres proches de celles d'une application native. 

Enfin, bien que les JVM soient les machines virtuelles les plus connues, 
il faut savoir que la plate-forme .NET de Microsoft reprend le concept de 
machine virtuelle. Ainsi, la machine virtuelle CLR {Common Language Run- 
time) execute un byte code note CIL {Common Intermediate Language). 
Microsoft fournit actuellement des compilateurs produisant du byte code 
CIL pour plusieurs langages : Visual Basic, C^^, C++ et meme Java. Des 
compilateurs pour d'autres langages comme Cobol, Fortran et Perl sont en 
cours de developpement. Cependant, du point de vue des applications distri- 
buees, la machine virtuelle CLR n'est pas pertinente du fait de la limitation 
de la plate-forme .NET aux systemes d' exploitation Windows (pour Linux, 
projet Mono en cours). Cela limite done considerablement la portabilite et 
I'interoperabilite de ce type d'applications. 

5 La solution de la technologie Java 

La technologie Java est composee d'un langage de programmation oriente 
objet (le langage Java) |lTj et d'un environnement d'execution (JVM). De 
nombreux frameworks et API {Application Programming Interface) per- 
mettent d'utiliser Java dans des contextes varies : systemes mobiles, Smart- 
Cards, etc. La maturite, la robustesse et la flexibilite du langage Java, ainsi 
que la richesse des bibliotheques et API de programmation I'accompagnant 
contribuent a faire de la technologie Java la plate-forme de reference pour 
les applications distribuees. Dans la suite, nous allons presenter brievement 
quelques caracteristiques du langage Java et de certaines bibliotheques, en 
mettant I'accent sur celles qui sont interessantes pour les applications dis- 
tribuees. 
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5.1 Caracteristiques 

• Langage specifiquement oriente objet 

Si le langage Java est connu pour sa simplicite relative (par rapport 
a d'autres langages), une de ses caracteristiques les plus marquantes 
est qu'il est strictement oriente objet. C'est-a-dire qu'il respecte I'ap- 
proche orientee objet de la programmation objet sans qu'il soit pos- 
sible de programmer autrement. En clair, contrairement a C-|— 1-, par 
exemple, on ne pent faire que de la programmation orientee objet avec 
Java. Cette specificite permet une meilleure lisibilite des programmes, 
avec une organisation plus structuree et un traitement des erreurs plus 
aise. Le langage Java ne dispose pas I'heritage multiple, neanmoins il 
offre plein de ses avantages sans les problemes associes par le biais des 
interfaces. 

• Fiabilite 

Une autre caracteristique non negligeable de Java est sa fiabilite. Cette 
fiabilite est notable en particulier dans sa gestion des pointeurs qui 
ecarte tout probleme d'ecrasement ou endommagement des donnees. 

• Integration 

Le langage Java permet I'integration de code natif (ce qui presente 
parfois certains risques de securite, car ce dernier pent manipuler 
directement la memoire) via I'interface native JNI {Java Native In- 
terface). Ceci implique que des codes existants, en C ou C-|— |- par 
exemple, peuvent etre integres dans un code Java. Meme si cette ap- 
proche semble mener a un code fragile et difficile a maintenir, elle 
represente une solution judicieuse au probleme d'integration. 

• Programmation multithreadee 

Creer des threads et les manipuler est tres facile dans le langage Java. 
Cette simplicite est I'une des raisons principales du succes de Java 
dans le developpement cote serveur. Le langage possede une collection 
sophistiquee de primitives de synchronisation entre plusieurs threads. 
En outre, dans les API de Java on trouve des classes qui facilitent 
davantage la programmation multithreadee. 

Le langage Java rend done possible I'utilisation de threads de fagon 
independante des plates-formes sous-jacentes, bien que de maniere im- 
parfaite. En effet, la portabilite des programmes n'est pas complete, 
car les threads ne sont implementes (a travers les differentes imple- 
mentations de JVM) de fagon identique sur les plates-formes (les ap- 
pels multithreads sont en revanche identiques). Ainsi, la technologie 
Java n'est pas completement independante de la plate-forme d'exe- 
cution a cet egard jl2]. Malgre cela, nous pensons que dans I'avenir 
la communaute Java adoptera une seule politique d'ordonnancement 
des threads, probablement Green Thread, dans toutes les implementa- 
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tions de JVM. Get article est d'ailleurs un encouragement aux efforts 
dc standardisation de I'implementation de I'ordonnanceur de threads 
dans les JVM. 

La migration de threads requiert un service de capture/restauration de 
I'etat des fiots de controle. Ce service, seul ou complete par d'autres, 
facilite la mise en place d'outils comme I'equilibrage de charge dyna- 
mique entre machines, la diminution du trafic reseau par migration des 
clients vers le serve ur, 1' utilisation de plates-formes a agents mobiles 
ou encore I'administration des machines. La tolerance aux pannes et 
le debogage des applications dependent egalement en partie de la mise 
a disposition d'un service de capture/restauration de I'etat des flots 
de controle. 

5.2 Modeles de repartition supportes 

Comme nous I'avons note plus haut, de nombreuses bibliotheques et API 
sont disponibles pour le langage Java. En standard, Java est livre avec une 

API evoluee comportant plus de 3000 classes appelees JFC {Java Fondation 
Classes). Ces classes sont tres perfectionnees, elles ont ete minutieusement 
etendues, testees et eprouvees. Enfin, elles couvrent un spectre tres etendu 
de besoins, comme la construction des interfaces utilisateur (AWT - Abstract 
Window Toolkit, Swing), la gcstion dc bases dc donnees (JDBC - Java Data 
Base Connectivity), I'internationalisation, etc. Par le biais de cette biblio- 
theque, Java supporte tons les modeles de repartition, tout en conservant 
les avantages recherches pour les applications distribuees. 

5.2.1 Communication par messages 

D'une part, Java dispose des fonctions permcttant de gercr les sockets. 
D 'autre part, le fonctionnement dans un environnement reseau de type Inter- 
net/Intranet est intrinsequement prevu, via la creation d 'applets executees 
dans un navigateur Web. En effet, une bibliotheque de routines permettant 
dc gcrer des protocolcs bases sur TCP/IP ou UDP/IP tels que HTTP ct FTP 
est disponible, on dispose ainsi de fonctionnalitcs reseaux a la fois fiablcs ct 
d'utilisation aisee. Les applications Java pcuvent charger et acceder a des 
objets sur Internet avec la meme facilite que si I'objet etait local. 

Java va au-dcla du transfert de messages structures, puisqu'il est pos- 
sible dc transferer des objets « proprement dit ». Pour realiscr cc transfert, 
Java utilise le mecanisme de serialisation, celui-ci consiste a convertir des ob- 
jets Java en un flux d'octets, afin de les reutiliser en effectuant I'operation 
duale (deserialisation) . Cette reutilisation pent etre immediate en les trans- 
ferant sur un reseau ou ulterieure en les stockant dans un fichier. II s'agit 
d'une caracteristique tres interessante, en particulier pour les applications 
necessitant un certaine persistance des objets ou de les envoyer. Ce meca- 
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nisme de serialisation/deserialisation est quasi-transparent pour I'utilisateur. 
D'ailleurs, JPVM (Java Parallel Virtual Machine), une implementation de 
PVM entierement ecrite en Java, permet aux fans de PVM de continuer a 
I'utiliser tout en profitant des nombreux avantages de la technologie Java. 



5.2.2 Objets partages 

Comme nous I'avons note precedemment, la memoire distribuee partagee 
correspond a une federation de la memoire physique de plusieurs machines 
distribuees en une memoire virtuelle unique. La memoire virtuelle resultante 
de cette federation est rendue accessible aux programmeurs a travers des 



bibliotheques dediees (cf. section 3.2 ). Cette bibliotheque etant ecrite suivant 
le modele de passage de message, rien n'empeche la technologie Java d'en 
fournir une. JavaParty f33| et Hive [3^ sont des exemples concrets d'une telle 
possibilite. II est egalement a noter que Hive offre la possibilite d'employer 
un des deux mo deles de coherence suivants : coherence sequentielle ou a la 
sortie. 



5.2.3 Appel de procedure a distance 

Le mecanisme de Remote Method Invocation (RMI) est une implementa- 
tion dite « tout Java » du RPC. C'est une API permettant de manipuler des 
objets Java distants, c'est-a-dire des objets instancies sur une autre JVM que 
celle de la machine locale. Ainsi, RMI permet d'atteindre un certain degre 
de portabilite. L'ensemble des communications se fait en Java, en utilisant le 
mecanisme de serialisation/deserialisation d'objets pour passer et recuperer 
les parametres des methodes distantes. De plus, ARMI |i5] (Asynchronous 
RMI), une version asynchrone de RMI, permet d'effectuer des appels non 
bloquants a distance. 



5.2.4 Logiciels mediateurs 

Finalement, la technologie Java renforce sa presence dans le monde des 
application distribuees avec son logiciel mediateur : JMS (Java Messaging 
Service) de la famille MOM. En outre, la technologie Java devant etre une 
solution strategique, I'integration et I'interoperabilite avec les differents lo- 
giciels mediateurs doit etre possible. De fait, Java permet I'integration de 
toute application possedant une interface ORB (Object Request Broker) 
comme C-|--|-, C^^, Smalltalk, etc. D'ailleurs, cette integration est simpli- 
fiee en Java a travers le package RMI-IIOP (Internet Inter-Orb Protocol) 
qui genere le code necessaire pour communiquer avec de telles applications. 
Parmi les autres solutions pionnieres d'interoperabilite, nous pouvons citer 
JNBridge qui assure I'interoperabilite entre Java et .NET. 
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6 Conclusion 

Dans un contexte distribue ou les machines et les reseaux sont hetero- 
genes, la technologie Java est la plus adequate pour la programmation des 
applications distribuees. EUc se traduit par une seule couche supplement aire, 
en roccurrence la machine virtuelle JVM, qui bien que ralentissant Icgere- 
ment I'execution, permet de garantir la portabilite, la securite, I'integration 
et I'interoperabilite des appHcations. En outre, la technologie Java offre ces 
garanties tout en donnant la possibilitc de coder des applications distribuees 
suivant n'importe quel modele de repartition. C'est pourquoi nous pensons 
que la technologie Java est une solution strategique, indispensable et incon- 
tournable pour la mise en oeuvre des applications distribuees. En particulier 
les applications tolerant une faible perte de performance. 
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